-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added -bump-to-next flag to control which component to bump if pre-release #36
Conversation
I made a mistake with pr #31 which ended up being closed because it did not have the right diffs. Sorry about that. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #36 +/- ##
==========================================
+ Coverage 79.59% 83.92% +4.33%
==========================================
Files 3 3
Lines 294 280 -14
==========================================
+ Hits 234 235 +1
+ Misses 49 34 -15
Partials 11 11 ☔ View full report in Codecov by Sentry. |
* main: Update circl to fix security issues Update CHANGELOG Add direnv config Ignore local .devbox env Add devbox configuration Update GitHub Actions Update depdendencies
Hej @yobeonline, I took the liberty to fix the linter issues in your pull-request. I will provide a review separately. |
Possible values are patch (default), minor and major.
Closes #29
Details
I created the custom enum-like type
TargetRelease
VersionComp
to hold values for the new flag. I gave it theValue
interface (methodsString
andSet
) so that the flags package can deal with this type on its own.The
String
method forTargetRelease
VersionComp
panics if the integer value is not one of the enums. I don't know if it is good practice to do that (i am a golang beginner), I just felt there was no other way to deal with this case.Using
patch
as default value preserves the previous behavior so that there should be no regression.